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BACKGROUND OF THE INVENTION 



1. Field of Invention 

This invention relates to a software simulation of a computer factory's automated system 
that downloads and installs purchased software packages to a computer being manufactured. This 
simulation allows the factory's automated software delivery system to be tested prior to 
implementation in a manufacturing environment. The invention simulates the manufacturing 
environment so that problems that would be encountered during the manufacturing process can be 
quickly corrected prior to being implemented on the manufacturing floor. 

2. Description of the Prior Art 

One stage in the manufacturing of a computer involves installing the appropriate software 
packages on the hard drive of the system. In this stage, operating system software, software 
required to drive the various hardware components, and application software are installed. 
Specifically, a personal computer is loaded with software applications according to a customer 
order. The nature of a personal computer (P.C.) requires that the software and components 
installed on the P.C. be configurable to a customer's needs. In other words, a customer may 
order a specific type of modem, hard drive, random access memory (RAM), monitor, and other 
hardware devices. Further, a customer may require a specific operating system such as Windows 
2000, or another specific operating system. Depending upon the use of which the customer is 
going to make of the P.C, various software applications are required. The configurable nature of 




the P.C. dictates that the manufacturing process of customer configurable P.C.'s to be able to 
handle lot sizes of one. 

In order for a manufacturing entity to be able to tailor a P.C. to a customer order, there 
5 exists a need for the installed software on each P.C. in a customer order to be configured on the 
manufacturing floor without human intervention. The most effective way to configure a P.C. is to 
use an automated process that downloads and installs software packages to each individual P.C. 
and further does various quality checks on the P.C. itself in order to determine that each hardware 
option is installed correctly. This installation should correspond to the customer order of the P.C. 
10 Traditionally, this process has been automated. The problem, however, is that inserting new 
models and options into the automated process requires extensive engineering man-hours to 
properly test these changes before they can be released to the manufacturing floor. 

This invention relates to a software download installation simulation. The process that is 
15 undergone on the manufacturing floor, is simulated by this invention. The simulation is performed 
in a testing environment or lab environment in order to determine whether the installation will be 
successful on the manufacturing floor. Not only does this invention create a more efficient 
manufacturing process, but this process also creates a more effective maintenance arena with 
respect to software reuse. This type of testing environment also creates a more cost-effective 
20 mode of testing the software download process prior to implementing the process in the 
manufacturing environment because it requires fewer engineering man-hours than the 
conventional manual method of testing a download system. 

A target computer is the computer being manufactured onto which software must be 
25 loaded to conform to customer specifications. At a given time on the manufacturing floor there 
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exists a plurality of target computers onto which a plurality of target-specific customer specified 
software packages must be loaded. 

The plurality of target computers are communicatively linked to a file server via a 
5 network, a direct connection or any other type of communications link known in the art. The file 
server can be a computer server of any type of platform, including but not limited to DOS, UNIX, 
or Windows™. 

A master token file resides on the file server. This master token file contains a list of all 
10 models and corresponding options that are available for download to a target system. Each model 
h i entry in the master token file is associated with a list of directives which, when executed will 
!:!*? install specific software onto the associated model. The master token file is copied from the 

:' : i 
: ~ 

: = server to the plurality of target computers via the communication link between the server and the 

i J plurality of target computers. Each target computer receives a master token file copied from the 

ii 15 server. This file can be sent to the target computers via FTP, a command line copy, or any other 

□ 

• J transferring mechanism available. 

§ P 

An informative file, an electronic traveler, resides on each target computer. The electronic 
traveler is responsible for recording the customer's order. Specifically, a reserved word is 
20 followed by a model type in the electronic traveler. The electronic traveler can contain other 
information about the specific requirements of the customer order. However, for the automated 
software download process to work, a model type must be indicated. Optionally, if one or more 
factory installed options have been ordered, then they are listed in the electronic traveler as well. 
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After the master token file is copied to the target computer, an independent process 
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creates a master batch file that is responsible for actually downloading, installing and checking the 
software deliverables. This master batch file is created by converging the model type information 
contained in the electronic traveler with the information contained in the master token file. This 
master batch file contains command lines that copy and execute the installation batch files for the 
5 ordered software packages. The master batch file begins the process of downloading the 
software. The master batch file originates a recursive process that installs each customer- 
requested software package onto the target computer. Each installation batch file is called in turn. 
These installation batch files branch out and execute programs that retrieve and install application 
software. 

10 

The problem with this process is that it must be fully executed to be tested. It must be 
executed in the lab for debugging. It must then be executed again on the manufacturing floor 
prior to its release acceptance. If an error were encountered in the sequential process of installing 
the various software modules on the target computer, the process would have to be stopped, and 

15 the error would then have to be fixed. Once the problem was fixed, the sequential process that 
installs the software on the target computer would then have to start over. After starting over, 
the process may get somewhat further in the installation procedure, however, it may run into 
another error. Again, the process would have to be stopped, and the problem would have to be 
fixed. The process would then have to be started over. This form of download testing must 

20 complete successfully before releasing it to the manufacturing department. The manufacturing 
department must successfully repeat the test on at least one target computer before releasing the 
process to general production. Manufacturing's test is designed to ensure that all of the software 
components of the download system are available to the target computers from manufacturing's 
array of download servers. When orders for a new product are released to manufacturing to be 

25 built, any flaw in the automated process will stop the factory. The down-time on the 
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manufacturing line associated with not performing this type of test sequence has a detrimental 
impact on the cost associated with building these target computers for customer delivery. The 
only way to avoid this down-time is through exhaustive testing which often leads to missing 
contractually obligated deadlines. A new process is needed to reduce the hours and days involved 
in the iterative debugging process. 

This invention creates, in a lab environment, a simulation of the software installation on 
the target computers for any specific combination of model and factory installed options. The 
testing environment is used to predetermine errors or problems that may occur in the download 
process. This predetermination, because it is confined to a lab environment or testing 
environment, does not create manufacturing floor down-time. Since the predetermination 
typically takes place in less than five minutes, hours of repetitive test downloading can be saved. 
Consequently, employing the simulation to predetermine the reliability of the installation process 
creates considerable manufacturing cost savings. 

The simulation is a process that determines the reliability and viability of the master batch 
file and all batch files that are recursively called from it. Prior to implementing a new software 
installation batch file in the manufacturing environment, the master batch file is tested by the 
simulation before beginning a download test. 
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SUMMARY OF THE INVENTION 



The present invention is a system and method of testing an automated software installation 



5 process. The process tested is used to custom load individual computer systems with end user 
specified software configurations. The invention simulates this process in order to discover errors 
and potential problems with the installation procedure before the procedure is used in production. 
These errors and problems can then be addressed in an efficient manner, avoiding the time and 
expense associated with curing such problems by using an iterative process of performing and 
10 then modifying the installation procedure. The simulation follows the steps an actual installation 
process would in a production environment. A dynamically created instruction file is created 
?3 which is dependant on the end user software specifications and model of the computer. These 
:::: instructions are checked to ensure that they can be successfully completed in the production 
ly environment. This test includes checking the flow integrity of the instructions, syntax of the 
15 instructions, resource integrity of the target computer, network integrity, and other management 



information systems utilized during the installation process. 



BRIEF DESCRIPTION OF THE DRAWINGS 
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FIG. 1 



Architectural Diagram of Manufacturing Floor Software Download 
Process 



FIG. 2 



Architecture of Software Download Simulation 
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FIG. 3 



FIG. 4 



FIG. 5 



Example of a Software Tree Examined by Simulation Process 
Highest Level Flowchart of System Software 
Steps Comprising Step 520 
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DETAILED DESCRIPTION OF INVENTION 



This invention employs technical elements necessary to simulate the manufacturing floor 
software download process. The architecture of the system employed on the manufacturing floor 
5 is illustrated in Fig. 1. The software download system comprises at least one file server 100a, a 
network 110, at least one target computer 120a, and a diskette 130. 

In the manufacturing environment, a diskette 130 is placed into a floppy drive on the target 
computer 120a. The diskette contains an electronic traveler that contains information necessary 
10 to determine the software to be downloaded from the file server 100a. The target computer 120a 
logs onto a file server 100a and obtains all necessary information required for the software 
r si download from the file server 100a to the target unit 120a. This information includes batch files, 

'=3 scripts, and application software. The application software can be either in a compressed or 

I; n 

j ! y uncompressed format. However, if the application software is in a compressed format, then a 
15 corresponding decompression software application must be downloaded to the target computer 
j J and the compressed software is then decompressed and written to the hard drive of the target 
computer 120a. 

i ; 

\* An effective implementation of this system comprises a plurality of file servers as 

□ 20 illustrated in Fig. 1. For example, the system can comprise file servers 100a, 100b, 100c, lOOd, 

lOOe, lOOf, lOOg, and 100b. This will allow a greater number of target computers to be loaded 

with software. 

The simulation tests the integrity of the software download process by examining several 
25 independent domains or areas: 1) Flow integrity of the batch files, 2) Resource integrity of the 
target computer, 3) Error reporting integrity, 4) Network integrity, and 5) Other Management 
Information Systems (MIS) and Diagnostic Systems. 
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These domains are general in nature. Through the use of configuration files maintained by 
the an engineer, the specifics of the engineer's resources, error reporting needs, network 
--architecture and other JvilS systems, the simulation camtddfess the sp ecifics of his insta llation by 
applying its internal rules to his unique environment. These simulated areas are discussed in detail 
herein. 



The Disk Space Simulation 

In order to simulate the disk space utilization, the engineer enters into a configuration file 
10 a number corresponding to the maximum amount of disk space that each drive letter can hold. 
This amount is referred to as the disk space fatal limit for each Unit Under Test (the UUT). The 
simulation detects when a batch file copies a target file from any location to the UUT. The 
simulation then examines this source file (usually on the network) and determines how much disk 
space it takes up. Subsequently, the original name of this file, the target name of this file, the 
15 target drive letter and the amount of disk space the file uses is added to a linked list. It then adds 
that amount to its internal current disk space used variable for that particular drive. If this 
number is greater than the peak disk space used variable, then the peak number is set equal to the 
current number. If the amount in the current disk space used variable is now greater than the disk 
space fatal limit for that drive letter, then a fatal error is generated. 

20 

Similarly, the engineer enters a number corresponding to the recommended maximum 
amount of disk space that each drive letter can hold. This number is usually slightly less than the 
disk space fatal limit. This is called the disk space warning limit for each Unit Under Test (the 
UUT) drives in the configuration file. If the amount in the current disk space used variable is now 
25 greater than the disk space warning limit for that drive letter, then a warning error is generated. 

Tf a file is d ele ted frnm - tho -HIJT^heTvthe deleted file's information is looked up in the 



linked list. The current disk space used variable for this3nv5ira*4he«sije^oftlus file subtracted 
from it. Then the node in the linked list is marked as deleted. Later, after the batch files are 
30 ^completely processed, we examine the list to determine which files are remaining each of the 



UUTs drives. A report is generated detailing the ending value of the peak disk space used and 
f] — -the current disk space used This information is then used to ensure that we return to the 

manufacturing process as much free disk space as we can and to ensure that no temporary files- 
are left on the UUTs hard drives. 

Since the batch file is processed sequentially by the simulation, these numbers are an upper 
bound on the amount of disk space used. 
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The Environment Space Simulation 



The engineer enters into a configuration file a number corresponding to the maximum 
amount of environment space that a UUT can address. This is called the environment space fatal 
limit. The simulation detects when a batch file sets an environment variable, examines this 
P environment variable to determine how much memory it takes up, then adds the name of this 
m 15 environment variable, the contents of this environment variable and their sizes to a linked list. It 

.... 7 

; 2 then adds those amounts to its internal current environment space used variable. If this number is 

^ 8 greater than the peak environment space used variable, then the peak number is set equal to the 

; .* current number. If the amount in the current environment space used variable is now greater than 



the environment space fatal limit, then a fatal error is generated. 



Similarly, the engineer enters a number corresponding to the recommended maximum 
amount of environment space that the UUT can address. This number is usually slightly less than 
the environment space fatal limit. This is called the environment space warning limit for the 
UUT. If the amount in the current environment space used variable is now greater than the 
25 environment space warning limit, then a warning error is generated. 

If an environment variable is deleted, then the information is looked up in the linked list. 
The current environment space used variable has the size of this variable and its contents 
subtracted from it. Then the node in the linked list has the variable contents deleted, but not the 
30 variable name. Later, after the batch files are completely processed this information is examined 
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to determine the state of the remaining environment variables. A list of the variables and their 
status is then printed into a report. All of this is done to make sure that we return to the 
manufacturing process as much free environment space as we can. 

Since the batch file is processed sequentially by the simulation, these numbers are an upper 
bound on the amount of environment space used. 

The Network Integrity Check 

The simulation performs all of its tests on one set of batch files on a network server. The 
server on which the test is performed is the Primary Server. Since there can be several other 
servers, called Secondary Servers, that should contain exactly the same set of files, the simulation 
does not again perform its integrity check on the mirrored servers. As the simulation encounters 
each copy command, it checks the date, time and size of the file being copied to the UUT. It 
compares those numbers to the date, time and size of the same file name on each of the Secondary 
Servers. If there are any differences, an error report is generated. 

The Batch File Flow Check 

The simulation processes the batch file in two passes in order to check the Batch File Flow 
characteristics. The first pass reads the labels in the batch file into a linked list. The second pass 
examines all goto commands. Each label from pass one (1) must have at least one corresponding 
goto or a Label Not Used* warning will be generated. If a label occurs on a lower line number 
than the goto command, a Backwards Flow* warning will be generated. If a goto command is 
trying to jump to a label that is not in the list, a Label Not Found 1 fatal error will be generated. If 
more than one label in the list is identical, a Duplicate Label 1 error will be generated. If a label is 
longer than the eight significant digits that DOS recognizes, but there is no other label having the 
same first eight characters, then a Label Too Long 1 warning will be generated. If a label is longer 
than the eight significant digits that DOS recognizes, and there is another label having the same 
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first eight characters, then a ' Significant Part Conflicts With Another Label • fatal error will be 
generated. 

The MIS System Interface Check 

5 

Some environment variables are reserved for use by interfaces to other management 
information systems that gather data from the manufacturing process. These interfaces look for 
these variables and look their contents up in databases. If no match is found in the database, then 
no data can be reported. The simulation examines the batch files for the reserved environment 
10 variables and looks them up in the database. If no match is found, an error is reported. This 
prevents large amounts of data from being lost during the manufacturing process. 

The examination described occurs prior to performing test downloads in order to release 
the new code to the manufacturing floor. The objective of the interpretive simulation is to step 
5,3 through each piece of the process to determine code consistency, errors and possible errors 

m 

y U 15 encountered in the process, so that the findings can be addressed prior to beginning the download 
testing. 

I The system and method of the present invention is now described with reference to Fig. 2. 

■;"! The basic architectural components of the simulation system comprises a file server 100a, a 

! U 20 network 110, a simulation unit 200 and a diskette 210. 

i.n 

; - In the lab environment a simulation computer 200 is connected to a network 110. On the 

network reside at least one file server 100a used in the manufacturing floor software download 
process, as described above. A file server 100a, for purposes of this invention, contains scripts, 
25 batch files, software applications, and other software necessary to prepare a target unit on the 
manufacturing floor with software in accordance with a customer order. 

All software necessary to boot the target unit is placed on a diskette. This diskette is then 
inserted into the target unit. The software necessary to connect to a file server and start the 
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download process is also written to this diskette. This includes an Electronic Traveler, which is a 
text file that identifies the model of the target unit and lists any Factory Installed Options (FIOs) 
requested by the customer. 

5 The interpretative simulation process begins by setting up on the simulation computer 200 

an environment that mimics the target computer 120a as described above and illustrated in Fig. 1. 
The simulation computer has access to all of the file servers lOOa-lOOh in the download. A 
diskette 210 is placed into the floppy drive of the simulation computer 200. The diskette contains 
an electronic traveler similar to the electronic traveler on the target computer in the manufacturing 
10 process. 

An electronic traveler can be any type of data file that identifies the model of the target 
J l computer for which the download process needs to be tested. A preferred embodiment of this 
i:! 1 data file is a text file with a reserved word corresponding to a key word. A reserved word is a 
: ~ 15 consistent identifier that alerts an accessing process of the text file of the correct line on which to 
Jj find the correct key word or token. For example, in each and every Electronic Traveler, the 

: - 

|,ia reserved word or symbol can be any unique, alphanumeric prefix. On the same line as this prefix 

□ is a token that identifies what type model or computer is being loaded with software. A token is 
P ij an alphanumeric string that is used to uniquely identify a model or FIO to the download system. 

:;L? 20 

=:=? 

□ A master token file resides on each of the file servers lOOa-lOOh located on the network 
110 to which the simulation computer 200 is connected. This master token file can be any type of 
data file that contains identifiers, or tokens that represent the different models of computers 
manufactured. Associated with each token in some format are the executable files, or batch files, 

25 necessary to load a particular model of computer with application software. 

The master token file is then copied to a local drive on the simulation computer 200. An 
initiation process creates a batch file that contains a sequence of instructions that will perform all 
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necessary steps in order to install the software indicated by the information in the electronic 
traveler. This process uses information from the electronic traveler and the master token list to 
dynamically create the main batch file. It retrieves out of the electronic traveler the model type. 
It retrieves out of the master token list the file names necessary to create the main batch file that is 
5 to reside locally on a target computer. This main batch file is dynamically created to install 
software on the exact target computer that was ordered. 

A batch file is an executable program that contains commands. In this instance, the 
specific commands included in the main batch file are dictated by the model of computer indicated 
10 for the software download. In the manufacturing arena the source code responsible for 
downloading software to a target computer is dynamically selected from an entire library of such 
routines and uniquely combined to match the target computer. An indicator in the electronic 
3 traveler and the master token file provide to the system the information necessary to build the 
!:!! executable responsible for downloading the software to the target computer. This batch file is the 

15 computer code that is examined by the interpretive element of this invention. Creating the batch 
I y file in the lab environment duplicates identically the batch file's creation in the manufacturing 

1 ~ environment. The same dynamic batch file that is responsible for downloading software to the 
O target computer is created in both the manufacturing and test environments. In the lab 
fy environment the same action is performed resulting in an executable file that, if executed, would 
^ 20 download to a target unit the required software. However, this batch file is not executed in the 
S3 lab environment. This file is interpretively simulated. 

The main batch file execution tree is diagrammed in Fig. 3. The top level indicated in the 
software tree is the dynamically created batch file 300. As the batch file is executed line by line, 
25 scripts or sub-batch files are executed. These are indicated in Figure 3 as 310, 320 and 330. As 
each sub batch file 310, 320, or 330 completes its execution, control is returned to the calling 
batch file. Most of these scripts or sub-batch files are, from a maintenance or development 
standpoint, static or non-dynamically generated code. These procedures are stored on one of the 
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file servers lOOa-lOOh. The execution of the main batch file begins a recursive process in that 
scripts, sub-batch files or procedures called by the initial batch file, in turn, can call other 
programs, procedures, scripts or sub-batch files, for example subl 310, sub2 320, and sub3 330. 
The sub batch files can call further procedures such as subsubl 340, subsub2 350, and subsub3 
5 360. If application software is requested, the scripts are responsible for downloading to the 
target computer the appropriate compressed application software and a means of decompressing. 

Once the application software is downloaded to the target computer and decompressed, 
the main batch file then manages a clean-up process to remove temporary files using cleaning 
10 scripts and sub-batch files. The result upon completion is that application software ordered by the 
customer is downloaded from one of the servers to a target computer and the target computer is 
left clean except for the software ordered by the customer. 

n In order to determine the integrity of this download process, the simulation processes each 

Lj 

z 15 line in each dependent sub batch file 310, 320, 330, procedure or script called by the main batch 

j file. As each call to a sub batch file is encountered, that sub batch file is processed before 

* continuing with the next line in the main batch file. 

. i 

il Batch files flow using conditional statements and GOTO commands. Each GOTO 

lj 20 command must have an accompanying label in order to for the batch file to function properly. An 
3 independent list of labels is maintained by the simulation for each batch file and sub batch file 
called during the manufacturing process. This process tracks real and potential errors in batch file 
flow control. Each batch file is monitored for several criteria that define good flow control. The 
label must be used at least once. The label must conform to the operating system's naming and 
25 size restrictions. There must be no duplicate labels. Additionally, labels can be made to conform 
to set naming conventions. For example, use of upper and lower case should be used 
consistently. All of these criteria are checked in seconds by the simulation program, which 
automatically does what would take several engineering man-hours to do manually. 
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The simulation models the management of the limited resources of the target computer. 
Resources include but are not limited to such concepts as environment variable space and disk 
space. As lines are encountered that modify the values in batch language's environment variables, 

5 the simulation updates an internal list of environment variables and their contents. It tracks and 
accounts for environment variables set and unset in this process. This process tracks real and 
potential errors in environment variable usage. If an environment variable is set and never used a 
warning is issued. If one is used but never set a fatal error is issued. As the simulation runs, it 
monitors the total memory that would be used by environment variables and issues warnings or 

10 errors when the amount of available memory during execution would run low or be exceeded. 



Simultaneously, with the aforementioned functions, the simulation process maintains a 
^ disk space log for each disc in the target system. As files are downloaded to the target computer 

j;;J disk space is used. If all the disk space on the floppy disc drive is used, a partition is created on 

i y 

,Z 15 the hard drive so that there will be enough memory to load all requisite software. In the 

i!3 

j'j simulation of this process, this software invention tracks the memory allocated and the memory 

r ~ freed in this process both on the hard drive and the floppy drive. The simulation monitors the 

■I 

i;3 upper bounds of memory and disk space requirements, monitoring peak usage and how much is 
I y still allocated when the download process passes control back to the manufacturing process that 
20 called it. 

E5 

The simulation determines error reporting integrity. As each program is called, certain 
error information like return codes or error files can be created. In a unique manufacturing 
environment using a plethora of programs written internally or developed by customers, vendors 
25 or others, no consistent rules can be applied to every program. But, using a configuration file 
maintained by the software engineer, standard error conventions available through the operating 
system can be checked for selected programs, as needed. This lets the engineer enforce unique 
and inconsistent error reporting needs in a consistent manner, far faster and with greater 
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thoroughness than could be achieved manually. 

The simulation further tracks network integrity. Network architecture will not only vary 
from one assembly line to another, but the same line will vary from day to day as typical 
5 maintenance will re-configure a network due to growth, scheduled maintenance, hardware failure, 
etc. The software engineer can describe the network in the simulation's configuration files as 
these changes occur. The examination of the network lets the simulation check to ensure that all 
mirrored copies of every file involved in the download system are up to date. The chief examples 
are for the detection of missing files, out of date files or corrupt files. By accomplishing this in 
10 seconds, the download test that follows can be assured of achieving the same results no matter 
what specific file server it is performed on. This typically results in a reduction in test time of 
over eighty percent. 

S3. 

;;! I The simulation explores and analyzes the required MIS systems. One of the problems that 

S :S 15 occurs when many MIS systems must communicate with each other continuously on a constantly 
\ j changing product line, is that they must implement some changes concurrently or massive system 
|! * failures result. A failure of this type could result in test data on thousands of target computers 
□ being lost or causing a line stoppage by the inability of the line to input the necessary data. By 

i y checking the MIS systems that interface to the download system being examined, errors can be 
20 caught before releasing to the manufacturing floor. 

ii 

Lastly, the simulation software creates reports that detail problems encountered during the 
interpretive simulation. These reports are used to address various problems that might be 
encountered on the manufacturing floor before time consuming tests of the download software 
25 are performed that would otherwise be needed to discover such potential problems. 

The steps that comprise the method and system of the present invention are described in 
FIG. 4. The first step in the process of simulating a software download is generating the Main 
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Batch File Based On Order Info 500. This can be accomplished in many ways known in the art, 
including but not limited, to manual creation of a batch file created by a person typing into a file 
on a computer those commands required to be executed to download the requisite software to a 
target computer. A preferred manner of creating this batch file is by running a stored process that 
identifies the model type of a computer being configured. The identification of the specified 
model is determined by data contained in the electronic traveler. The process then searches the 
master token file to determine what subroutines must be executed in order to meet the required 
specifications. 

Once the batch file 500 is created for the model type of computer the software loading of 
which is being simulated, the next step is to read the file and make a list of labels 510 employed in 
the batch files to determine the batch file flow integrity. For example, one type of label is a 
GOTO statement. This invention determines that a GOTO statement has a corresponding line to 
which to begin as indicated by the number or label following the GOTO statement. 

Once the main batch file flow integrity is confirmed, the next step in the method is to read 
the main batch file again, recursively determining the integrity of each sub batch file 520 called by 
the main batch file. An example of a possible software tree that is being simulated is indicated in 
FIG. 3. In applying the system and method of this simulation to this software tree, the main 
batch file 300 is analyzed for flow integrity in step 510. Once 510 is accomplished, the next step 
is to evaluate the sub batch files 310, 320 and 330 which involves repeating step 510 with respect 
to each of the sub batch files. This process continues until the integrity of each of the batch files 
in the software tree is evaluated. 

The next steps involve evaluating interfaces to other MIS and Diagnostic Systems 530, 
verifying network domain 540, and examining the ending environment 550. 

The recursive method step 520 of evaluating each batch file is further described in FIG. 5. 
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Each line of each batch file simulated is read in 620. If the line is a comment, as opposed to a 
command, the next line is read 630. If the command being evaluated is a call to another batch file, 
the batch file being called from the batch file currently being simulated is read and the process 
creates a list of labels used in the batch file being called 510. If the line currently being simulated 
5 is neither a comment nor a call to another batch file, the line is evaluated according to internal 
system rules 650. 

Internal rules contain information necessary for the program to determine whether a line in 
a batch file will execute successfully. For example, a line in a batch file may command the system 
10 to execute a file. If the file is downloaded to the system in a zipped format, the simulation 

determines that the file is zipped, then insures that the corresponding unzip utility is also located 
on the system so that the file can be executed. Another example of the application of internal 
t rules is a line that sets an environment variable. The simulation uses internal rules to determine 
[j that the environment variable is set to an acceptable value dictated by the system. 

;j Once the internal rules are applied to each line in a batch file, the simulation updates the 

* environment accordingly 660. 

*% 
si 

jl It will be apparent to those skilled in the software development art as applied to 

Lj 20 manufacturing that various modifications and variations can be made to the present invention 
3 without departing from the spirit and scope of the invention. For instance, the system and method 
of the present invention can be employed in industries other than the personal computer 
manufacturing industry. Moreover, those of ordinary skill in the art will recognize that various 
computer programming languages could be used to construct the system and method of the 
25 present invention. Thus, it is intended that the present invention cover the modifications and 
variations of this invention provided they come within the scope of the appended claims and their 
equivalents. 
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